A user interface is a portion of a program with which a user interacts. Types of user interfaces, or UIs (in the idioms of computer engineering), include command-line interfaces, menu-driven interfaces, and graphical user interfaces. A windowing environment, which uses a graphical user interface, is an operating system or shell that presents the user with specially delineated areas of the screen called windows, which may be resized and moved around on the display of a computer. The Macintosh OS and Microsoft Windows are both examples of windowing environments. Graphical user interfaces are one of the means by which a user interacts with an application, which is a program designed to assist in the performance of a specific task, such as word processing, accounting, or inventory management. Graphical user interfaces allow a user's action in one window to cause an application to open another window. In such a case, the original window, which caused the new window to be opened, appears behind the new window. Many applications allow an unlimited number of such windows to be open at the same time. However, a user can generally interact only with the top-most window. As a result, the top-most window is said to be the active window. All other windows are said to be inactive windows.
Windows can be classified as modeless or modal. If an active window is modeless, a user is able to make any inactive window active by using a pointing device to click on any portion of an inactive window that is visible to a user. If, however, an active window is modal, a user cannot activate other windows until the active window is closed. For example, a user may have to complete a task in the active window, which is modal, such as filling in some fields and pressing an OK button to close the active window before other windows can be activated.
An active window that is modal may open another window, which will become active and modal, on top of it, and so on. Only the top-most active window that is modal is active. All other windows, whether they are modal or modeless, are inactive and cannot be activated until the active modal window is closed. Applications use modal windows as detours away from some primary task to perform an auxiliary task. Once a user closes a modal window, the operating system reactivates the original window that the user employed to activate the modal window. Returning a user to the original window effectively completes the detour, thereby allowing a user to continue with his original task.
FIG. 1 illustrates an interactive help utility called a wizard 100, which appears as a modal window, within an application. The wizard generates windows that guide a user through each step of a particular task, such as starting up a word processing document in the correct format for a business letter. The GUI window of the wizard 100, like other window applications, includes a title bar 102, which is a horizontal space at the top of a window that contains the name of the window. Appearing as a square button in the right corner of the title bar 102 with an X mark on it is a close button 104. Clicking on the close button 104 cancels the wizard 100. The wizard 100 also includes a number of screens 106, 108, and 110, that present information and receive input (information) from a user during the performance of the task defined by the wizard. The screens 106-110 may be navigated back and forth using a back button 112 or a next button 114. After collecting sufficient information from a user, the wizard 100 presents a finish button 115. A user clicking the finish button causes the wizard 100 to proceed to perform the wizard's task. At any point, a user may exit from the wizard 100 by clicking on a cancel button 116. Clicking on the cancel button causes the wizard 100 to quit and returns the user to the application that originally invoked the wizard 100.
Wizards and similar programs work fine for the purpose for which they were designed. However, because of various constraints, wizard-type programs are typically not used in user interfaces for interacting with various applications. The main problem with the wizard-type programs is their modal nature. When a wizard presents a question to a user, the user must contemporaneously have sufficient information to answer the question or must cancel the entire process. Because of the modal nature of wizard-type programs, a user cannot reactivate the application that has invoked the wizard or other applications to gather information with which to answer a question presented by the wizard. In various usability studies, users have complained that they feel forced down a particular, and unknowingly lengthy, path by a wizard. In certain wizards, the next button 114 is unclickable until a user has answered the presented question, thereby preventing the user from skipping a question that the user has insufficient information to answer. Another problem is the lengthy linear sequence of screens of wizards. A user may have sufficient information to answer many screens of questions only to find out near the end of the wizard screens that a question cannot be answered, thereby forcing the user to quit the wizard prior to completion. A further problem is that wizards must follow a rigid dialog template without deviation. Besides the fixed screen dimensions within which the wizard is presented to the user, navigational facilities within the wizard are limited to the back button 112, the next button 114, or the cancel button 116. Given these constraints, a wizard is more appropriately used in the context of a help utility rather than as a user interface for complex applications.
The linear rigidity employed by wizards to force a user to interact in a specific manner in order to accomplish a desired task is overcome by Web-style applications, such as Microsoft Money 2000. An example of a Web-style application 200 is shown in FIG. 2. A Web-style application is not a Web site, but it shares many properties in common with Web sites. The user interface of the Web-style application 200 shown in FIG. 2 consists of a plurality of full-screen pages 202, 220, and 230, shown in a shared frame 201, with tools for navigation, such as a back button 206, a forward button 208, and a Home button 210. The user interface of the Web-style application 200 may also include a title bar and a close box like the wizard 100, but are not shown here for brevity purposes. The shared frame 201 includes a navigation bar 204 that contains the name of the page being displayed in the shared frame 201, as well as the navigation controls i.e., the Back button 206, the Forward button 208 and the Home button 210.
The first page of the Web-style application 200 is a Home page 202 which includes a list of tasks that a user can select to be performed. The tasks are invoked by clicking on a hyperlink, such as a pay a bill hyperlink 212, a balance an account hyperlink 214, or a track a stock portfolio hyperlink 216. When one of these hyperlinks, 212-216, is activated, a “process,” which consists of a page or series of pages that are employed to perform the selected task, is invoked.
In the example shown in FIG. 2, a process 218 is invoked when the user selects the pay a bill hyperlink 212. The invoked process 218 includes two pages 220, 230. A number of exemplary payable bills are presented on the first page 220, namely, a Cablevision bill 222, an AT&T bill 224, and a City Power bill 226. Each of these bills 222-226 is presented as a hyperlink. Clicking on one of these hyperlinks causes the bill associated with the hyperlink to be paid, as noted in the title bar 204. The first page 220, additionally, allows a user to view bills that are one month away by clicking on a hyperlink 228. When this hyperlink 228 is clicked on, the second page 230 is shown. The second page lists an exemplary bill from MSN. This bill is associated with a further hyperlink 232. Clicking on the further hyperlink 232 causes the bill from MSN to be paid (as noted in the title bar 204). When a user is finished with the bill paying task, the user may click on another hyperlink 234 titled, for example, “I am done paying bills”. When this hyperlink is clicked, the Web-style application 200 automatically represents the Home page 202, i.e., the page from which the user initially launched the bill paying process 218.
This behavior of always returning a user to the page that launched the invoked process is not achieved through a hard-coded hyperlink on the final screen of the process, such as the last page 230 of the process 218. This is because the destination of the final hyperlink may vary, and a hard-coded hyperlink cannot anticipate the precise launching page from which a process is invoked. Instead, the Web-style application 200 implements the behavior of always returning a user to the page that invoked a process in a different way. More specifically, the Web-style application 200 maintains a stack of launching pages that are independent of the normal navigation offered by the back button 206 and the forward button 208. When a user launches a process, the launching page is pushed onto the stack. When a user clicks the done hyperlink on the final screen of the process, the Web-style application 200 pops the most recent launching page off the stack and returns the user to that page.
Unlike the linear rigidity associated with the wizard 100 illustrated in FIG. 1 and discussed above, at any point during the operation of the Web-style application 200, a user may navigate backward or forward from any page, even the pages included in an invoked process, such as the process 218. When a user does navigate away from a page in a process, the page that launched the invoked process remains active on the stack. Thus, the user can still complete the process by backing up to the page where he left it and will always be returned to the launching page because of the stack. This process allows a user to make a detour or back up, and then go on with a process. Thus, the non-linear-structure of Web-style applications overcomes many of the limitations of wizard-type applications.
The dynamism of the user interface of a Web-style application that allows a user exploration is ensured by the steadfastness of the stack in that the stack always returns the user to the launching page from which a process is invoked. While a significant advance, the constant interposition of launching pages can hinder Web-style application from forming super-processes that comprise the functionalities of two or more processes. This hindrance is illustrated in FIG. 3A, which shows a Web-style application 300 at a macroscopic level, i.e., without a shared frame and page details. A Home page 302 includes a hyperlink that, when clicked, brings a user to a Launching page 304. The Launching page 304 contains one or more hyperlinks, including a hyperlink to invoke a first process 306. When the first process 306 is invoked, the Launching page 304 is placed on a stack, and the first page, page A 308, of the process 306 is displayed. As discussed before, a user may navigate away from the pages of the process 306, or the user may navigate through the first process 306 by working with the pages of the process, namely, page A 308, page B 310, and the final page, page C 312, to complete the task associated with the process. The Launching page 304 is popped from the stack and represented to a user when a hyperlink on first page C 312 of the first process 306 is selected to indicate the completion of the task associated with the process 306.
If the user desires to perform a second task associated with a second process 322, the user must click another hyperlink contained in the Launching page 304. Clicking this hyperlink causes the first page of the process 322, page X 316, to be displayed. From page X 316, the user can progress to the next page Y 318 and then to the final page, page Z 320, to complete the second task. Similar to the invocation of the first process 306, the Launching page 304 is again pushed onto the stack prior to the presentation of the pages of the second process 322. At the conclusion of the second task, the Launching page 304 once again is popped from the stack and represented to the user.
In the past it has not been possible for a designer of the user interface of the Web-style application 300 shown in FIG. 3 to combine the functionality of a first process 306 with the functionality of a Web-style application, such as a second process 322 while keeping each of the process pages 308-320 separate so that each page can be used in other contexts. The undesired interposition of the Launching page 304 in the Web-style application 300 prevented a seamless user interface experience between the presentation of the pages of the first process 306 and the presentation of the pages of the second process 322. The only way to provide the functionalities of both of the processes 306, 322 is to combine the pages of each of the two processes 306, 322 in another process.
Besides the problem of assembling two or more processes without interference by the interposition of the launching pages, the processes of previously developed Web-style applications are designed with no thought that these processes may be reused to form new functionalities in other applications. This problem is better illustrated in FIG. 3B, which shows a partial navigational flow 326 is taken from a Web-style application of the type shown in FIG. 3A. The partial navigational flow 326 includes the Launching page 304 from which the first process 306 is invoked. The first page of the first process 306 is page A 308, and the remaining pages are page B 310 and page C 312. When exiting from the process 306, the Launching page 304 is popped from the stack and represented to the user.
As shown, each of the pages 304-312 is tightly coupled to a database 326 where data is shared. To use the database 326, each of the pages 304-312 must intimately know all the data that can be written to or read by the other pages. Otherwise, one page could mistakenly access and change data in the wrong place in the database 326 resulting in the corruption to the rest of the pages and possibly detrimental repercussions to the Web-style application 300. Unfortunately, this requirement results in the data in the database 326 being vulnerably exposed by necessity to all of the pages 304-312. The lines 328A-328J are included to show the data access paths of the pages 304-312.
To summarize, in the past, Web style applications were developed separately from one another. It was not envisioned that the processes employed by Web-style applications might be used outside the context of Web-style applications for which they were designed. This resulted in Web-style application processes being tightly coupled to a data source, such as the database 326, which is specific to a particular application domain. AS a result, prior Web-style applications are Web-like only in that the pages and the pages of the processes are linked together in a complex, non-sequential web of associations in which the user may browse in a single application. But a process in one Web-style application cannot access a process in another Web-style application unless the data of one application is completely exposed to the other application. This presents a serious security problem. Additionally, this is similar to the proscription in computer science in the use of global variables to store states across functions because global variables limit reuse and makes understanding code difficult.
The problem of tight coupling is further illustrated in FIG. 3C, which illustrates a first process 306 of the type associated with the Web-style application 300 shown in FIG. 3A and a further process 336 associated with another Web-style application. As discussed before, the pages of the first process 306 (page A 308, page B 310 and page C 312) are tightly coupled to a first database 326. The pages of the further process 336, which includes page U 338, page V 340, and page W 342, are tightly coupled to another database 344. The lines 328C-328G are included to show the data access paths of the pages of the first process 306, and the lines 346A-346F are included to show the data access paths by the pages of the further process 336. Given the tight coupling between the first process 306 and the first database 326, and the tight coupling of the further process 336 and the second database 344, it is difficult to combine the functionality of the first process 306 and the functionality of the further process 336. To do so would require a user interface designer to be intimately familiar with the relationship between the first process 306 and the first database 326, and the further process 336 and the second database 344. Not only would this be a time-consuming undertaking, but it may also hinder the efficiency of designing and improving Web-style applications.
As noted above, exposure of the data of a process poses a security risk. For example, suppose that the first process 306 and its database 326 are designed by Corporation A, and the further process 336 and its database 344 are designed by Corporation B. Suppose further that it would be synergistic for the functionality of the first process 306 to invoke the functionality of the further process 336. The only way to do so at present is for Corporation A to completely expose the data associated with the first process 306 stored in its database 326 to Corporation B, and for the Corporation B to completely expose the data associated with the further process 336 stored in its database 344 to Corp oration A. Such exposure creates a security risk for Web-style applications designed by both Corporations A, B.
FIG. 3D illustrates another problem associated with the tight coupling design of previously developed Web-style applications. FIG. 3D illustrates a first process 306 tightly coupled with its database 326 as discussed before. Another process 350, which comprises page R 352, page S 354, and page T 356, is tightly coupled to a related database 360. Lines 358A-358F are included to illustrate the data access paths of the pages of the other process 350 to its database 360. Another level of tight coupling is shown by lines 348A-348F. These lines are illustrative of the data accesses between the pages of the first process 306 and the pages of the other process 350. FIG. 3D shows that there may be three levels of tight coupling, each of which may inhibit and hinder the ability of a user interface designer to reuse processes of previously developed Web-style applications. One level is the coupling between the first process 306 and its database 326. Another level of tight coupling is between the other process 350 and its database 360, and the final level is the coupling between the first process 306 and the other process 350. If a user interface designer desires to use either the first process 306 or the other process 350 with another Web-style application, the designer will find it extremely difficult to do so. The only way to reuse either the first process 306 or the other process 350 is to completely expose the data of both processes, which, as noted above, creates a security risk.
Thus, there is a need for an architectural software framework for designing Web-style applications that incorporates protocols and means for expansion and interfacing with other Web-style programs, as well as a reusable basic programming structure that assists in building secured Web-style applications, while avoiding the foregoing and other problems associated with existing Web-style applications.